FIG. 20 shows a network configuration using IP (Internet Protocol). In FIG. 20, communication nodes 100 (communication node 100a and communication node 100b) are communication nodes that perform communication using IP. When a forwarding node 200 receives an IP packet transmitted by a communication node 100, it determines a forwarding destination of the IP packet and forwards to the determined forwarding destination. Forwarding nodes repeat this, and ultimately forward the IP packet to a communication node that is the destination.
In determining the forwarding destination of the IP packet, the forwarding node 200 uses a routing table held internally. The routing table is a table indicating which network destination packet should be transmitted, though which interface, to a forwarding node that takes on the next forwarding processing; and a corresponding destination network address, next forwarding destination IP address, and destination interface are listed in the table as one entry. The entry includes information outside of the abovementioned information, but here this is omitted for simplicity.
The network address is an address obtained by extracting a number of upper bits of an IP address, and is expressed in a format such as 192.168.1.0/24. In this case, the upper 24 bits of the address are the network address, and addresses from 192.168.1.1 to 192.168.1.255 are included in the network in question. On this occasion, 24 is called a prefix length.
When appropriate route information is determined from the routing table, the forwarding node 200 uses a method known as a longest match method. This is a method in which a destination address of the IP packet and respective entries of the routing table are compared, to determine an entry where there is a match of a longer number of bits from an upper bit of the destination address.
The routing table is set in advance by a method such as a manual setting in the forwarding nodes 200, or automatically by a protocol for exchanging route information called a routing protocol.
In an IP network, packets are forwarded by the above forwarding method, but there is a problem in that, in this case, packet forwarding depends on the routing table of the respective forwarding nodes, and paths cannot be completely controlled. Furthermore, since the forwarding destination is determined by only the destination address, there is a problem in that exact path control is not possible due to differences concerning which application the communication is performed by, or of source address.
As a way of performing the above-mentioned path control, there is a method known as source routing. Source routing is a method in which a node that is a source (for example, communication node 100a) explicitly lists up, in a packet to be transmitted, addresses of forwarding nodes 200 that are desired to be in a forwarding path. In this case, the communication node 100a can forward a packet to a node (for example, communication node 100b) that is a destination by a forwarding path intended by an application or the like that is being used.
Furthermore, in packet forwarding technology known as MPLS (Multi-Protocol Label Switching) also, technology exists that corresponds to source routing. MPLS is a technology in which a label is assigned to a received packet, and forwarding processing is performed based on the label.
Assigning the label is performed when, after the packet is received by a forwarding node arranged at a boundary of an MPLS network, the packet is forwarded, and forwarding nodes inside the MPLS network thereafter repeat forwarding processing while re-attaching the label each time the packet is forwarded. When forwarding to an external network by a forwarding node arranged at the boundary of the MPLS network, the label is removed by the forwarding node in question.
In the MPLS, technology corresponding to the source routing is CR-LDP (Constraint Routing-Label Distribution Protocol). LDP is a protocol for exchanging the label among forwarding nodes in the MPLS network, and with an object of traffic engineering or the like, LDP, which has an object of strictly indicating a packet forwarding path, is CR-LDP.
Patent Document 1 discloses a method where, in an ad hoc network, the total amount of control packets can be reduced, not by having all mobile terminal devices transmit link information between neighboring mobile terminal devices, but by only a mobile terminal device, which is a cluster head, transmitting the link information.
Furthermore, similarly with regard to performing path control, Non-Patent Document 1 proposes a technology known as OpenFlow. In OpenFlow, communication is taken as end-to-end flow, and path control, recovery from failure, load balancing, and optimization are performed in flow units. An OpenFlow switch functioning as a forwarding node is provided with a secure channel for communication with an OpenFlow controller, and operates according to a flow table in which appropriate addition or rewriting is indicated by an OpenFlow controller. In the flow table are definitions of sets of rules for collation with packet headers, actions defining processing content, and flow statistical information.
For example, when an OpenFlow switch receives a first packet, an entry is searched for, which has a rule (FlowKey) conforming to header information of the received packet, from the flow table. As a result of the search, in a case where an entry conforming to the received packet is found, the OpenFlow switch implements processing content described in an action field of the entry in question, with respect to the received packet. On the other hand, as a result of the search, in a case where an entry conforming to the received packet is not found, the OpenFlow switch forwards the received packet to the OpenFlow controller via a secure channel, requests determination of a path of the packet based on source and destination of the received packet, receives a flow entry for realizing this, and updates the flow table.
[Patent Document 1]
Japanese Patent Kokai Publication No. JP-P2007-235444A
[Non-Patent Document 1]
Nick McKeown, and 7 others, ‘OpenFlow: Enabling Innovation in Campus Networks’, [online], [search conducted Jul. 17, 2009] Internet URL: http://www.OpenFlowswitch.org//documents/OpenFlow-wp-latest.pdf